Software-defined networking is an emerging architecture for data transfer networks. In a software-defined network “SDN”, the control plane is separated from the data plane so that the control plane is implemented in one or more controllers that can be separate from the network elements and the data plane is implemented in the network elements. The network elements can be, for example, Internet Protocol “IP” routers, multiprotocol label switching “MPLS” nodes, packet optical switches, and/or Ethernet switches. Each network element may consist of a single apparatus or a combination of a plurality of apparatuses. Typically, the software-defined networking allows for quick experimenting and optimization of switching and/or routing policies and external access to the innards of network elements that formerly were closed and proprietary.
Internet Protocol “IP” based networks were initially built based on the concept of Autonomous Systems “AS”. This concept allows networks to scale and extend by connected junctions that forward packets to a reasonable next hop based on partial need-to-know information. The AS principle works much like the traditional post office service, where a postal worker in a given city does not need to know all the tenants of all the streets in another city in order to choose a reasonable next hop for a letter at hand. This approach to networking is simple, and has proven resilient and scalable. This approach has, however, a few drawbacks. It does not allow the designated destinations, or tenants with home mail-boxes, to move without changing their identity as far as the packet delivery service is concerned. The topological location of destinations, which is the network interface they are attached to, dictates their identity related to the packet delivery service. In addition, using only the basic AS principle, it is hard to specify other qualities, such as logical grouping, access control, quality of service, intermediate network processing, or to specify aspects that relate to a sequence of packets that form a flow.
In the following, the software-defined networking is illustrated in a simplified manner using the analogy to the postal service. For any given street location, the software-defined networking works so that all the letters from all the tenants would first be aggregated by a network element on an edge a software-defined network. This network element is configured to examine the current location for each of the letter-destinations using a global lookup mechanism. Based on that global lookup and on other globally defined and globally measured considerations, such as access control or remote location load conditions, the said network element places one or more of the original letters in an additional envelope addressed to each of the street locations where the destinations currently are. It then uses the normal postal service which works like the traditional Internet Protocol “IP” to get these outer envelopes to the remote locations. This is done based on the existing and scalable hop-by-hop forwarding services. The outer letters are then opened by a remote network element and the original envelopes are delivered to the destinations. It is to be noted that the above-presented analogy between the software-defined networking and the postal service is a strong simplification and it gives only a limited viewpoint about the versatile possibilities provided by the software-defined networking.
The software defined networking is, however, not free from challenges. Some of the challenges are related to configuring the network elements. When configuring a network element, the controller sends to the network element configuration data with the aid of which the network element constructs a configuration system. The configuration system enables the network element to operate as a part of a software-defined network “SDN”. The configuration system may comprise for example one or more look-up tables defining actions to be carried out in different operational situations.
In a software-defined network, many events which may cause a need to verify the integrity of the configuration system of a network element may take place. The verb “to verify” is to be understood in the broad sense so that it may cover for example checking the integrity of the configuration system, restoring the integrity of configuration system, reconstructing the configuration system, and/or any other process for ensuring the congruency between the configuration system and the status of the controller. Events causing the need to verify the configuration system can be, for example, a case where a connection between the controller and the network element has been lost and subsequently re-established, a case where the operational responsibility is received by the network element from another network element, a case where the management responsibility is received by the controller from another controller, a case where the controller sends to the network element a notice message indicating the need to verify the configuration system, etc. The configuration system of the network element can be, however, quite large and thus it may take time to verify the whole configuration system and moreover the required amount of data that needs to be transferred between the controller and the network element can be significant.